Every day, you struggle with a huge ugly beast that wants to:
- Grow larger
- Get uglier
- Devour you
- Trick you
- Steal your resources
- Waste your time
- Drain your life away
- Make senseless extra work for you
- Turn what should be easy projects, into difficult projects
- Ruin your reputation with both your customers and your managers
- Prevent you from planning for the future
- Make your systems unreliable
What is this beast?
It is the main disease of complex systems.
Over the years, it has had many names, such as "Bureaucracy" and "Inefficiency". A currently popular term for it is "Technical Debt".
In prior posts, we started to explore the causes of this disease, identifying that a primary cause is the intrinsic complexity of the host system.
Complexity
A comprehensive understanding of complexity will take us a long way toward taming our beast. This is because complexity is at the root of the symptoms we wish to control.
For example, why might it take "too long" to add a new feature to your system?
- Hard to figure out where to make the change?
- Hard to understand what the system is currently doing?
- Afraid of "breaking" the system?
- Not sure if the change will have unforeseen consequences?
Interestingly, we can prefix each of these with "Because the system is so complex, ":
- Because the system is so complex, its hard to figure out where to make the change
- Because the system is so complex, it is hard to understand what the system is currently doing
- Because the system is so complex, I am afraid of "breaking" the system
- Because the system is so complex, I'm not sure if the change will have unforeseen consequences
In the prior post, we directly related complexity to dependency. This will turn out to be critical as we develop strategies for coping with complexity. When applied to the above example, we can develop a good sense for a directly contrasting situation:
- Because there are few dependencies, its easy to figure out where to make the change
- Because there are few dependencies, it is easy to understand what the system is currently doing
- Because there are few dependencies, I am not afraid of "breaking" the system
- Because there are few dependencies, I'm sure the change will have no unforeseen consequences
Methodology
The best overall methodology for combating complexity is to reduce the number of dependencies. The challenge is to accomplish this while minimizing disruption to ongoing operations, and at an acceptable cost. Luckily, there are effective techniques for doing this.
Next
In the next post, I will discuss a powerful technique for reducing a system's overall complexity by reducing the overall degree of dependency between components. Ironically, this may sometimes involve increasing the number of dependencies in some areas.